home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text1099.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  5.0 KB  |  135 lines
  1. > From: grobe@ukanaix.cc.ukans.edu (Michael Grobe)
  2. > To: www-talk@nxoc01.cern.ch
  3. > Date: Mon, 10 May 93 14:49:41 CDT
  4.  
  5.  
  6. > chapter 6 of the march 15, 1993 version of "Hypertext Markup  
  7. Language
  8. > (HTML)" by Berners-Lee and Connolly discusses "Link Relationship  
  9. values."
  10. > 
  11.  
  12. > i have several questions about this chapter:
  13.  
  14. > first, what is its status? are there browsers in use that recognize
  15. > these link attribute values? have any of these attributes been  
  16. promoted
  17. > to be part of the standard?  are they likely to become part of the
  18. > standard? if so, when and under what authority?
  19.  
  20. They have not been promoted to part of the standard, but if they
  21. are tested they could be.  RFCs don't become standards without
  22. implementations.  No browsers that I know of implement them though
  23. many people have expressed great enthusiasm.  The thing will go
  24. in RFC direction, the authority will therefore be IANA and the IETF
  25. or whatever officially is the authority in the nwo (IAB? ISoc?)
  26.  
  27. > second, if browsers ignore attribute values that they do not  
  28. recognize, why
  29. > must these "experimental" values be preceded with "X-".
  30.  
  31. This scheme (which is used for many Internet standards) means
  32. that ifyou invent a scheme which puts a certain semantics on
  33. a new relationship, you can guarrantee that the scheme won't break
  34. because someone just happens to use it for something else with
  35. different semantics.  During the test phase, you can't be SURE
  36. that noone else thought of the same X-relation, and that their
  37. documents will totally confuse your software.  (though it is
  38. unlikely especially with a this list running)
  39.  
  40. > third, are there any example documents showing the use of these  
  41. values?
  42.  
  43.  
  44. Nope (correct me?).  [[Historical note:  The first hypertext system I  
  45. wrote used typed links.  An interesting result was
  46. that though I had initially imagined that the number of link
  47. types would grow without bound, in fact I settled down with a
  48. dozen or so having all the semantics there seemed to be
  49. beteween the things I was making notes about]].
  50.  
  51. > fouth, is the value "Made" correctly described in this chapter?
  52. > the chapter says that Made means that the:
  53. > 
  54.  
  55. >    Person (etc) described by node A is author of, or is responsible  
  56. for B
  57. > 
  58.  
  59. > where A is the source document and B is the destination document.  
  60. however, 
  61.  
  62. > the chapter also says that one use for the value is "for sending
  63. > mail to authors," and it seems to me that Made would be more useful  
  64. if
  65. > A and B were reversed in the definition above.
  66. > that is, it seems more useful for a document to contain a pointer  
  67. to a file
  68. > describing an author where the link relationship would be "Made"  
  69. with
  70. > the understanding that the person described in B is the author of  
  71. A.
  72. > can someone clarify this (what seems to me to be a) discrepancy?
  73.  
  74. Every link type can be used in a REL attribute or in a REV
  75. attribute (or in some -- non acyclic -- cases conceivably both).
  76. The REV attribute is just the same, but the direction is
  77. reversed.  This saves having to have a convention for
  78. naming reverse link types such as "made-by".
  79.  
  80.  
  81. > fifth, since we are looking for a way to connect html documents  
  82. with
  83. > their authors or responsible authorities, the value Made appears to  
  84. be
  85. > a possible approach.  but, i would be interested in knowing any  
  86. other
  87. > conventions for recording such information that may be planned or  
  88. under
  89. > discussion.  i would actually prefer (at least intuitively) to have
  90. > a tag defined for the document <head> section that could be used to
  91. > record responsibility for the document.  for example, <owner> could
  92. > be defined and have name, organization, and e-mail address as  
  93. attributes.
  94. > our browser could then pick up the owner e-mail address for posting
  95. > comments from users reading a particular file directly to the  
  96. owner.
  97. > in particular, we might have the following tag 
  98.  
  99. >      <owner name="Michael Grobe" e-mail="grobe@kuhub.cc.ukans.edu">
  100. > comments?
  101.  
  102.  
  103. Whilest any useful additions to HTML for HMML are open to
  104. discussion now, I would like to see more generic forms used.
  105. This is because HTML is not an application-specific document
  106. type, it is in fact a great big compromise which allows enough
  107. fairly generic structures to represent most things anyone wants.
  108. If "owner" can be represented as a generic relationship, between
  109. a document and a person, with a particular type, then I would
  110. prefer the generic form to be used rather than a specific tag  
  111. invented.  I think this will make processing easier, also expansion,
  112. and keep the DTD small.
  113.  
  114. <LINK REV=MADE HREF="whois:S=Grobe;G=Michael;O=Ukans">
  115.  
  116. Here is one example of something which is
  117. easier to do is a web traversal filtered by relationships. Consider
  118. "Give me a list of (and fire :-) all the people who have MADE  
  119. software which is USED BY this program and for which there is no  
  120. document which DESCRIBES that software" 
  121.  
  122. or, "Print out all documents which this document recursively INCLUDES
  123. to any depth", and so on.
  124.  
  125. > :michael grobe
  126. > academic computing services
  127. > the university of kansas
  128.  
  129.  
  130.  
  131. Tim Berners-Lee
  132. CERN
  133.  
  134.  
  135.